1. Field of the Invention
The invention relates generally to storage controllers and more specifically relates to supporting collection and verification of data integrity information.
2. Discussion of Related Art
A computer system typically comprises or connects to a storage system for storing data used by the computer system. The storage system typically comprises a storage controller for reading/writing data to/from a storage device. The storage device may be any of a number of devices including a hard drive that stores the data on a platter. However, a block of data written by the storage controller out to the storage device (and eventually to a storage media including the platter) may not be the same block of data later read in by the storage controller from storage device.
To provide better assurance that the same block of data written out by a storage controller is also read back, the industry has started to employ a Data Integrity Field (“DIF”) for validating a data block. Typically, a DIF is 8 bytes long and a data block is 512 bytes long. When the storage controller writes out a data block to the storage device, a DIF generated based on the data block is also written out. When the storage controller reads in the data block from the storage device, the previously written DIF is also read in. The storage controller can then use the previously written DIF to validate that the data block has not been changed since the data block was previously written out.
However, many storage devices continue to only support 512 byte blocks, which is sufficient to store a typical data block but not its DIF. One solution implemented in a storage controller is to store a group of DIFs (for a corresponding group of data blocks) in their own Data Integrity Block (“DIB”) on the storage device. In order to support this solution, storage controller manufacturers have implemented software in the storage controller to create the DIB, and to validate the DIFs within the DIB.
However, the DIB is created and/or updated whenever a data block needs to be written out. The DIFs within the DIB are also verified whenever data blocks are read in. Executing software to handle these new processing needs uses processing power of a processor of the storage controller, thus adding overhead to the storage controller and reducing the capability of the storage controller to perform other tasks. Additionally, the storage controller typically creates the DIB in a local cache memory before writing the DIB out to the storage device, and verifies the DIB in the local cache memory after reading in the DIB. But processing the DIB in the local cache memory is slow and inefficient. For example, accessing the local cache memory, which usually comprises Dynamic Random Access Memory (“DRAM”), involves significant latencies that delay the speed of both reading and writing DIFs/DIBs within the storage controller.
Thus it is an ongoing challenge to support collection and/or verification of data integrity information.